Skip to main content

who — Inspect Live Session Activity

Learning Focus

By the end of this lesson, you will be able to identify active users, spot suspicious remote sessions, correlate idle terminals with risk, and use session data during WordPress maintenance and incident response.

Overview​

who reads the login session database and reports who is currently connected, from which terminal, and when sessions started. It gives you real-time visibility into access activity.

For WordPress VPS operations, this helps prevent conflicting maintenance actions and supports rapid detection of unexpected logins.

Tool Snapshot
  • Core Function: Display currently logged-in users and session metadata.
  • Primary Benefit: Immediate session visibility for security and operations decisions.
  • Where to Use: Pre-deploy safety checks, suspicious-login triage, admin shift handoffs.
  • Workflow: who [OPTIONS].

who is part of GNU coreutils and is available by default on Ubuntu.

System Check​

Ensure who is available and check your version:

which who        # Expected: /usr/bin/who
who --version    # Shows coreutils version

Syntax & Expression Rules​

The command follows a logical structure that reads almost like a sentence:

who [OPTIONS]
  • [OPTIONS]: Output controls such as -H, -q, -u, -b, and -a.
  • (no option): Standard view of active sessions.
  • (pipelines): Combine with awk, grep, or last for deeper investigation.

Session Inspection Flags​

ExpressionDescriptionExample Syntax⭐ Rating
:--:--:--:--
(no flag)List current sessionswho⭐⭐⭐⭐⭐
-HShow column headerswho -H⭐⭐⭐⭐
-qShow usernames + user countwho -q⭐⭐⭐⭐
-uInclude idle time and process IDwho -u⭐⭐⭐⭐⭐
-mShow current terminal onlywho -m⭐⭐⭐
-bShow last system boot timewho -b⭐⭐⭐⭐
-aShow extended all-style detailswho -a⭐⭐⭐
-TShow terminal write statuswho -T⭐⭐
-dShow dead processes (if present)who -d⭐⭐

Monitoring Actions​

ActionDescriptionWordPress/VPS Use CaseExample Syntax
:--:--:--:--
List active SSH sessionsFocus on remote terminalsConfirm authorized maintainers during releasewho | grep pts
Count concurrent usersQuick occupancy checkAvoid overlapping production editswho -q
Inspect idle sessionsFind unattended login shellsReduce hijack riskwho -u
Correlate live + historical accessCombine current and past login dataIncident investigationwho && last -n 5

Practical Use Cases​

1. Display all active sessions​

who

Expected output:

wpadmin  pts/0  2026-02-23 08:12 (203.0.113.15)
siteops  pts/1  2026-02-23 09:03 (198.51.100.42)

Explanation: Shows active logged-in accounts and remote origin when available. Use case: Pre-maintenance visibility check.

2. Add readable headers for reports​

who -H

Expected output:

NAME     LINE   TIME             COMMENT
wpadmin  pts/0  2026-02-23 08:12 (203.0.113.15)
siteops  pts/1  2026-02-23 09:03 (198.51.100.42)

Explanation: Improves readability for copied audit output. Use case: Incident notes and handoff documentation.

3. Count active users quickly​

who -q

Expected output:

wpadmin siteops
# users=2

Explanation: Prints compact list and total sessions. Use case: Decide whether maintenance window is clear.

4. Check idle duration and process IDs​

who -u

Expected output:

wpadmin pts/0 2026-02-23 08:12 00:00 22410 (203.0.113.15)
siteops pts/1 2026-02-23 09:03 01:45 22542 (198.51.100.42)

Explanation: Adds idle timers and PID values. Use case: Detect unattended sessions before privileged changes.

5. View only your current terminal session​

who -m

Expected output:

wpadmin pts/0 2026-02-23 08:12 (203.0.113.15)

Explanation: Prints only the active terminal identity. Use case: Confirm identity inside nested SSH hops.

6. Check last reboot before troubleshooting​

who -b

Expected output:

system boot  2026-02-23 07:58

Explanation: Indicates when host last restarted. Use case: Validate timeline during outage review.

7. Filter likely SSH sessions only​

who | grep pts

Expected output:

wpadmin  pts/0  2026-02-23 08:12 (203.0.113.15)
siteops  pts/1  2026-02-23 09:03 (198.51.100.42)

Explanation: Focuses on pseudo-terminal remote sessions. Use case: Check whether remote access matches expected operators.

8. Investigate unknown source IPs quickly​

who | awk '{print $1, $5}'

Expected output:

wpadmin (203.0.113.15)
siteops (198.51.100.42)

Explanation: Extracts user and source column only. Use case: Compare against known office/VPN ranges.

Common Mistakes & Troubleshooting​

ProblemCauseFix
:--:--:--
No output from who on remote nodeNo active login sessions in utmpConfirm with last -n 5 and ensure you are on intended host
IP address missing in outputLocal console/TMUX session or display manager loginCorrelate with ss -tnp | grep sshd for remote socket context
Unexpected duplicate user linesUser has multiple terminals openValidate each TTY and close stale sessions
Time values look incorrectServer clock drift or timezone mismatchCorrect with sudo timedatectl set-ntp true and verify timezone
Suspicious user appears activeCredential/key compromise or shared credentialsLock account with sudo passwd -l USER, terminate session, review /var/log/auth.log

Best Practices​

  • Run who before production changes: Avoid conflicting edits by concurrent operators.
  • Correlate live and historical logs: Pair who with last and auth logs during triage.
  • Investigate unknown IPs immediately: Treat unfamiliar origins as high-priority events.
  • Close idle privileged sessions: Reduce hijack risk in long maintenance windows.
  • Use per-user accounts: Session visibility is only useful when identities are unique.

Hands-On Practice​

Task: Perform a Session Safety Check Before Deployment​

  1. Run who -H and verify every active session belongs to approved operators.
  2. Run who -u to identify idle sessions and close unnecessary terminals.
  3. Challenge: Build a pre-deploy check script that aborts deployment when unknown source IPs appear in who output.

Connection to Other Concepts​

  • groups: Validates what each active user is allowed to access.
  • id: Confirms full identity details for suspicious or privileged sessions.
  • sudo: Helps determine which active users can run elevated commands.
  • userdel: Use after repeated unauthorized session findings for final offboarding.

Visual Learning Diagram​

What's Next: Proceed to adduser — Create Linux Users for Controlled Access to build safer onboarding workflows after session auditing.